「原來如此，原來在建立類型的時候加上冒號就可以將其他類型的方法拿來用！」勇者又理解了一個符號的用途。

「嗯⋯⋯」蕭凱琪猶豫了一下，還是說了出來。「其實非必要的話，不要這麼做比較好。」

「有隱患嗎？」勇者很敏銳的察覺蕭凱琪有未盡之語。

「當你繼承財富的時候也順便繼承了債務。」蕭凱琪頓了頓，繼續說：「我先說清楚，像這樣加上冒號，被稱為繼承和實現。繼承的話就是屬性和函式可以直接拿來用，但是實現的話就和Number類型一樣，屬性和函式只提供名字，其他都要自己實現，但也因此比繼承靈活，可以實現好幾個介面，而不像繼承只能對應一個類別。」

「那就都使用實現就好了啊？」勇者聽蕭凱琪說的話覺得實現比較好。

「如果事情有這麼間單，繼承這種設計就不會留下來了啊。」蕭凱琪笑了。「每個擴展方式設計都有它的優點，繼承的好處就是，當你有個地方希望所有類型一起改，就只要改被繼承的類型就好，不用擔心漏掉，但缺點也是這個，當你想製造例外，就要特別細心。」

蕭凱琪用了雙親的債務增加，若子女不特別去放棄繼承，債務也會跟著增加的例子，勇者很快就理解了繼承的優缺點。

「那只有這兩種擴展方式嗎？」勇者問。

「有的，委託和組合也是很常見的擴展方式，尤其是委託，更是最近流行的作法。話說，『委託』這詞還真的讓我有點陌生，平常我和其他人都直接用英文Delegate。」蕭凱琪解釋了一下用詞原因：「就是個習慣，工程師說話常常中英交雜的。大概是有些英文詞語聽起來比較專業？而且用原文就不用擔心每個人翻譯的差別了。」

「所以組合平常也不是用組合這個稱呼？」

蕭凱琪肯定了勇者的猜測：「嗯，用英文Composition。」

蕭凱琪聳肩：「總之，Composition和Delegate的做法都是傳入參數，只是Delegate可以做到直接呼叫傳入參數的函式，不用額外指定執行函式的對象。耦合度低了可維護性就高，也不會降低可讀性。說起來，之前用IntelliJ IDEA寫程式碼的時候，也收過它提供的耦合度低的建議寫法。」